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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and reguests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


This document describes a method for identifying the originating 
calling party in the headers of a stored voice mail message. Two new 
header fields are defined for this purpose: Caller_ID and 

Called Name. Caller_id is used to store sufficient information for 
the recipient to callback, or reply to, the sender of the message. 
Caller-name provides the name of the person sending the message. 
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1. Introduction 


There is currently a need for a mechanism to identify the originating 
party of a voice mail message, outside of the "FROM" header 
information. The telephone number and name of the caller are 
typically available from the telephone network, but there is no 
obvious header field to store this in an Internet Mail message. 


This information is intended for use when the VPIM message format is 
used for storing "Call Answer" voice messages in an Internet Mail 
message store, i.e., the calling party leaves a voice message for the 
recipient, who was unable to answer the call. The implication is 
that there is no RFC 2822 address known for the originator. 


[VPIMV2R2] suggests the originating number be included as an Internet 
address, using the first method shown below. There are several other 
ways to store this information, but they all involve some 
manipulation of the "From" field. For example: 


1. From: "416 555 1234" <non-mail-user@host> 


2. From: "John Doe" <4165551234@host> 
3. From: unknown:; 
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Since any of these is a forced translation, it would be useful to 
store the calling party"s name and number as presented by the 
telephone system to the called party without manipulation. This 
would allow the calling party’s information to be displayed to the 
recipient (similar to it appearing on the telephone) and also allow 
future determination of an Internet address for the originator (if 
one exists). Note that there is no requirement to store meta-data 
(e.g., type of number, presentation restricted), as this information 
is not presented to the called party and is generally not available 
to voice mail systems. The intent is to store the available 
information to an analog (non-ISDN) phone (e.g., per [T1.401] in 
North America). 


[RFC2076] currently lists "phone" as an Internet message header which 
would hold the originating party’s telephone number, but it is listed 
as "non-standard", i.e., usage of this header is not generally 
recommended. It also has no defined format, making the information 
unparsable. There is no similar entry for the originator’s name. 


It is proposed that two new message header fields be included to hold 
this information, namely the Calling Line Identification ("Caller- 
ID") and Caller Name ("Caller-Name"). 


2. Conventions Used in this Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, [RFC2119]. 


3. Calling Line Identification Field 


The Calling Line Identification header ("Caller-ID") holds sufficient 
information for the recipient’s voice mail system to call back, or 
reply to, the sender of the message. The number that is contained in 
this header is supplied by the telephone system. The exact format of 
the data received depends on the type of call, that is -- internal or 
external call. 


Note that for both options, the number field MUST contain only the 
digits of the number and MUST be representable using the American 
Standard Code for Information Interchange [ASCII] character set; it 
does not include any separating character (e.g., "-"). 


It is expected that default, likely to be the most common case, will 
not have any numbering plan semantic associated with the number. 
However, in the case that it is known, an optional "NumberingPlan" 
parameter MAY be used to indicate the semantic. 
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ols Internal Call 


For an internal call (e.g., between two extensions within the same 
company), it is sufficient to relay only the extension of the calling 
party, based on the company dialing plan. 


However, the support of longer numbers may be supported by the 
enterprise phone system. 


-2. External Call 


For an international call, the calling party’s number must be the 
full international number as described in [E.164], i.e., Country Code 
(CC), National Destination Code (NDC), and Subscriber Number (SN). 
Other information, such as prefixes or symbols (e.g., "+"), MUST NOT 
be included. [E.164] allows for numbers of up to 15 digits. 


For a call within North America, it is also suggested that 15 digits 
per [T1.625] be supported. However, some service providers may only 
support 10 digits as described in [T1.401] and [GR-31-CORE]. Though 
it is desirable that an international number not be truncated to 10 
digits if it contains more, it is recognized that limitations of 
various systems will cause this to happen. 


Implementors of this specification should be aware that some phone 
systems are known to truncate international numbers, even though this 
behavior is undesirable. 


Note that the other defined fields available to non-analog systems 
(e.g., Subaddress, redirecting number), as well as the meta-data, are 
not intended to be stored in this header. 


3. Numbering Plan 


In this baseline case (i.e., analog lines), no numbering plan 
information is known or implied. However, in the case that a 
numbering plan is known, an optional "NumberingPlan" parameter MAY be 
used to indicate the semantic. Only three semantics are defined: 
"unknown", "local", and "e164". "unknown" is the default if no 
numbering plan semantic is known (and the default if the parameter is 
absent). "local" has meaning only within the domain of the voice 
mail system that stored the message (i.e., the voice mail system 
knows that the number belongs to a local numbering plan). "e164" 
indicates that the number is as described in [E.164]. "x-" may be 
used to indicate enterprise or service specific dialing plans. 
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3.4. Date Header 


The date and time may be included by the telephone system with the 
calling party"s telephone number per [T1.401]. This MAY be used, as 
there is an existing "Date" Internet header to hold this information. 
It is a local implementation decision whether this time or the local 
system time will be recorded in the "Date" header. 


4. Caller Name Field 
The name of the person sending the message is also important. 
Information about whether the call is internal or external may be 
included if it is available. This information may not be available 


on international calls. 


Further, the exact format for this field is typically a service 


provider option per [T1.641]. It is possible for the caller’s name 
to be sent in one of several character sets depending on the service 
provider signaling transport (e.g., ISDN-UP, SCCP, TCAP). These 
include: 


1) International Reference Alphabet (IRA), formerly know as 
International Alphabet No.5 or IA5 [T.50] 

2) Latin Alphabet No. 1 [8859-1] 

3) American National Standard Code for Information Interchange 
[ASCIT] 

4) Character Sets for the International Teletex Service [T.61] 


Of these, the IRA and T.61 character sets contain a number of options 
that help specify national and application oriented versions. If 
there is no agreement between parties to use these options, then the 
7-bit character set in which the graphical characters of IRA, T.61, 
and ASCII are coded exactly the same, will be assumed. Further, the 
7-bit graphical characters of [8859-1] are the same as in [ASCII]. 


Note that for delivery to customer equipment in North America, the 
calling name MUST be presented in ASCII per [T1.401]. 


As a result, for the caller name header defined in this document, 
characters are represented with ASCII characters. However, if a name 
is received that cannot be represented in 7-bit ASCII, it MAY be 
stored using its native character set as defined in [RFC2047]. 


In telephone networks, the length of the name field MUST NOT exceed 
50 characters, as defined in [T1.641]. However, service providers 
may choose to further limit this to 15 characters for delivery to 
customer equipment, e.g., [T1.401] and [GR-1188-CORE]. 


Parsons & Maruszak Standards Track [Page 5] 


RFC 3939 Calling Line Identification December 2004 


3% 


6. 


6. 


Formal Syntax 


Both Calling Line Identification and Caller Name follow the syntax 
specification using the augmented Backus-Naur Form (BNF) as described 
in [RFC2234]. While the semantics of these headers are defined in 
sections 4 and 5, the syntax uses the ’unstructured’ token defined in 
[RFC2822]: 


unstructured = *([FWS] utext) [FWS] 


.1. Calling Line Identification Syntax 


"Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan=" 
( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF 
ietf-token := <An extension token defined by a 


standards-track RFC and registered 
with IANA.> 


x-token := <The two characters "X-" or "x-" followed, with 
no intervening white space, by any token> 


-2. Caller Name Syntax 


"Caller-Name" ":" unstructured CRLF 


.3. Examples 


To: +19725551212@vml1.example.com 
Caller-ID: 6137684087 
Caller-Name: Derrick Dunne 


To: 6137637582@example.com 
Caller-ID: 6139416900 
Caller-Name: Jean Chretien 


Other Considerations 
1. Compatibility with Other Internet Phone Numbers 


The intent of these headers are to record telephone number that is 
sent by the analog phone system with an incoming call without 
alteration or interpretation. If sufficient semantic is known or can 
be inferred, this may be included in the NumberingPlan field. This 
may allow it to be later translated into an addressable phone number. 
Addressable or dialable phone numbers (which this document does not 
define) are defined in other documents, such as GSTN address 
[RFC3191] or telephone URL [RFC2806]. 
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6.2. Usage 


There are a few scenarios of how this mechanism may fail that must be 
considered. The first is mentioned in section 3.2 - the truncation 
of an international number to 10 digits. This could result in a 
misinterpretation of the resulting number. For instance, an 
international number (e.g., Írom Ireland) of the form "353 91 73 
3307" could be truncated to "53 91 73 3307" if received in North 
America, and interpreted as "539 917 3307" - a seemingly "North 
American" style number. Thus, the recipient is left with incorrect 
information to reply to the message, possibly with an annoyed callee 
at the North American number. 


The second scenario is the possibility of sending an internal 
extension to an external recipient when a Call Answer message is 
forwarded. This poses two problems, the recipient is given the wrong 
phone number, and the company’s dialing plan could be exposed. 


The final concern deals with exercising character options that are 

available in coding the Calling Name field. An international system 
may send a message with coding options that are not available on the 
receiving system, thus giving the recipient an incorrect Caller Name. 


7. Security Considerations 


Note that unlisted and restricted numbers are not a concern as these 
header fields are defined to contain what the called party would see 
(e.g., "Private Name’), as opposed to the complete details exchanged 
between service providers. 


However, it must also be noted that this mechanism allows the 
explicit indication of phone numbers in the headers of an email 
message (used to store voice messages). While the rationale for this 
is reviewed in section 1, the recipient of this message may not be 
aware that this information is contained in the headers unless the 
user’s client presents the information. Its use is intended to be 
informative as it is when it appears on a telephone screen. 


8. IANA Considerations 


This document defines an IANA-administered registration space for 
Caller-ID numbering plans in section 5.1. Each registry entry 
consists of an identifying token and a short textual description of 
the entry. There are three initial entries in this registry: 


unknown - The number’s semantics are unknown. This value is the 
default in the absence of this parameter. 
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local - The number only has meaning within the domain of the 
sending system identified by the RFC 2822 From field of 
the message. 


e164 - The number’s semantics are described in [E.164]. 


The only way to add additional entries (ietf-token in section 5.1) to 
this registry is with a standards-track RFC. 
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